Kaxil why is this required? We can just release regular wave of provider with RC for the needed provider

@kaxil @jedcunningham What is the added value of beta for providers? I can just cut a release wave for providers.

The idea was to just do the minimum needed to get the beta cut today, and not have to go start a vote etc on top of everything else.

Agreed with Elad on proceeding with betas for now and Elad will cut rc's post that

Agreed with Elad on proceeding with betas for now and Elad will cut rc's post that

Yeah. This is a bit outlier in the current processes of ours and doing it this way for now is good. It might get a bit tricky with Airflow 3 rcs because some of the providers will have to be relased effectively before Airflow 3 is out and we might have to release them together or in a quick succession or possibly together I think when we release Airflow 3.0.0rc* we should assume that a "wave" of releases will contain both Airflow and the subset of providers that we will have to release together.

That means that for installing airlfow rc with pip we will have to use --pre flag when telling people how to install airflow 3 RC https://pip.pypa.io/en/stable/cli/pip_install/#install-pre but that's pretty fine for "RC" release of Airflow 3 I think - even if it means that we can accidentally install some other RC and dev candidates of external dependencies (that's an unfortunate effect of --pre flag having a global effect on all packages) - but this will be mitigated if we use RC constraints that will use speciflcally RC versions of all the providers that will be released to support Airlfow 3 release.